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Abstract 


The Virtual Circuit Connectivity Verification (VCCV) protocol 
specified in RFC 5085 provides a control channel (CC) that is 
associated with a pseudowire (PW). This document specifies an 
additional VCCV control channel type to be used with pseudowires that 
do not use the PW Control Word and that are carried over an MPLS 
network. This new VCCV CC type uses the Generic Associated Channel 
Label defined in RFC 5586 to distinguish VCCV packets from packets 
carrying user data. This new VCCV CC type introduces compatibility 
with the method of MPLS Label Switched Path Operations, 
Administration, and Maintenance (OAM) identification, particularly in 
MPLS Transport Profile (MPLS-TP) networks (RFC 5921). 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7708. 
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1. Introduction 


The Virtual Circuit Connectivity Verification (VCCV) protocol is 
specified in RFC 5085 [RFC5085]. This document specifies a new VCCV 
control channel (VCCV CC) type to be used with pseudowires (PWs) 
carried over an MPLS network that do not use the PW Control Word (CW) 
[RFC4385]. This new VCCV CC type uses the Generic Associated Channel 
Label (GAL) [RFC5586] to distinguish VCCV packets from packets 
carrying user data. This new VCCV CC type provides compatibility 
with the method of MPLS Label Switched Path (LSP) Operations, 
Administration, and Maintenance (OAM) message identification, as used 
in MPLS Transport Profile (MPLS-TP) networks [RFC5921]. 
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VCCV currently specifies three CC types.  VCCV CC Type 1 uses the PW 
Control Word (CW) to distinguish VCCV packets from packets carrying 
user data.  VCCV CC Types 2 and 3 require IP encapsulation for OAM 
packets. This was not an issue when [RFC5085] was designed, but it 
is in conflict with the design goals of MPLS-TP [RFC5921], which do 
not otherwise require the availability of IP.  VCCV CC Type 2 is not 
applicable to Multi-Segment PWs (MS-PWs) [RFC6073]. A MS-PW 
operating without the CW therefore has to use VCCV CC Type 3, which 
identifies VCCV packets on the basis of Time to Live (TTL) expiry. 
Whilst less of an issue with a single segment PW (SS-PW), on an MS-PW 
this requires accurately setting the TTL for expiry at the egress 
Terminating Provider Edge (T-PE) [RFC6073]. In the event of an error 
in the setting of the PW Label Stack Entry (LSE) TTL, VCCV packets 
will not be received by the Terminating Provider Edge (T-PE) and may 
leak into the attachment circuit [RFC6073]. The new VCCV CC type 
defined in this specification addresses these problems for PWs that 
do not use the CW. 


Note that mandating that PWs use the PW CW is not a viable way to 
address this issue. This is because: 


o PWs without the CW are already widely deployed. 


o There is a significant deployment of existing hardware that does 
not support usage of the PW CW for some PW types. 


o Some operators are concerned that the inclusion of the PW CW will 
increase the PW packet size. 


2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


3. Type 4 MPLS VCCV Control Channel Type 


When the PW CW is not used, the Type 4 MPLS VCCV Control Channel (CC) 
type defined in this section MAY be used. This is referred to as 
VCCV CC Type 4 throughout the rest of this of this document.  VCCV CC 
Type 4 uses the encapsulation shown in Figure 1 in which the presence 
of a GAL at the end of the MPLS label stack indicates that the packet 
carries a VCCV message. 
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Figure 1 


The VCCV message body is preceded by a Generic Associated Channel 
Header, as defined in [RFC5586], in which the Channel Type identifies 
the type and format of the OAM message carried in the VCCV message 
body. 


The GAL LSE MUST contain the GAL reserved label as defined in 
[RFC5586]. 


The PW LSE is constructed according to the existing procedures that 
apply to the type of pseudowire that is in use. 


Where the LSP used by the PW is subject to Equal-Cost Multipath 
(ECMP) load balancing, a problem arises if any LSR on that LSP treats 
special-purpose labels as ordinary labels in its ECMP selection 


method. In these circumstances, the inclusion of a GAL following the 
PW LSE can cause the OAM packet to take a different path through the 
network than the corresponding PW data packets. If the LSP traverses 


such equipment and this behaviour is not acceptable, then an 
alternative VCCV type needs to be used. The requirement to not 
include special-purpose labels in the load-balancing decision is 
described in "MPLS Forwarding Compliance and Performance 
Requirements" [RFC7325]. For equipment that conforms to this, the 
VCCV type 4 traffic will follow the corresponding PW data packets. 


4. FAT PWs 


[RFC6391] specifies that when the flow-aware transport (FAT) of 
pseudowires over an MPLS packet switched network has been signalled 
or configured, the Flow LSE MUST be present. It further specifies 
that "the flow label MUST NOT be an MPLS reserved label (values in 
the range 0..15) [RFC3032]", and that "If a flow LSE is present, it 
MUST be checked to determine whether it carries a reserved label. If 
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it is a reserved label, the packet is processed according to the 
rules associated with that reserved label; otherwise, the LSE is 
discarded." 


This document specifies that if the flow-aware transport of 
pseudowires over an MPLS packet switched network has been signalled 
or configured, then the presence of VCCV message is indicated by the 
use of a GAL in place of the flow LSE. 


This is consistent with [RFC6391], and the packet structure is 
identical to that shown in Figure 1. 


Flow LSEs are inserted into a PW label stack in order to enable the 
distribution of the PW traffic among multiple equal-cost MPLS paths. 
The use of GAL in place of the flow label will cause all OAM packets 
to take exactly one of the possible paths through the network. As 
noted in Section 3, the ECMP selection method may result in the path 
taken by the OAM packets being different from the path taken by any 
of the actual traffic flows. If this is not acceptable, then an 
alternative VCCV type needs be used. 


5. Multi-Segment Pseudowires 


When using VCCV CC Type 4 for MS-PWs, a PE transmitting the VCCV 
packet to a Switching PE (S-PE) MUST set the TTL to the appropriate 
value to expire at that S-PE. An S-PE that supports this 
Specification MUST inspect PW packets that are received as a result 
of TTL expiry, and determine whether a GAL follows the PW LSE. Ifa 
GAL is present, the S-PE then processes the VCCV packet. 


An S-PE that does not support this specification would be expected to 
reject as malformed a VCCV CC Type 4 packet that was received. This 
is because the S-PE would expect the PW LSE to be the bottom of stack 
(the non-FAT case) and for the LSE at the bottom of stack not to be a 
reserved label (both the FAT and the non-FAT cases). An S-PE that 
did not make this reserved label check would then find that the first 
nibble following the label stack was 0x1 and not the expected start 
of an IP packet. Thus, it would be expected to also reject the 
packet. This update to the behaviour of S-PEs is therefore backwards 
compatible. 


6. VCCV Capability Advertisement 


The VCCV capability advertisement MUST match the C-bit setting that 
is advertised in the PW FEC element [RFC4447]. If the C-bit is set, 
indicating the use of the PW CW, then VCCV CC Type 4 MUST NOT be 
advertised. If the C-bit is not set, indicating that the PW CW is 
not in use, then equipment supporting this specification MUST 
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advertise VCCV CC Type 4. Advertisement of VCCV CC Type 1 and 
advertisement of VCCV CC Type 4 are therefore mutually exclusive. 


A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as 
defined in [RFC5085] 


If the remote PE supports VCCV CC Type 4, and the PW CW is not in 
use, then for cases where multiple CC Types are advertised, the 
following precedence rules apply when choosing which CC Type to use: 


1. Type 4: GAL VCCV Control Channel. 
2. Type 2: MPLS Router Alert Label. 
3. Type 3: MPLS PW Label with TTL -- 1. 


If the remote PE finds that VCCV CC Types 1 and 4 are both 
advertised, or that C-bit is set and VCCV CC Type 4 is advertised, 
then it should report the error to the operator through the 
management interface in use, and send a Label Release Message with a 
status code "VCCV Type Error". 


7. Manageability Considerations 


Whilst the introduction of this additional VCCV CC type increases the 
number of VCCV CC types that the operator needs to manage, it 
addresses the issues with VCCV CC Types 2 and 3 described in 

Section 1. 


In the event of a misconfiguration of this VCCV CC type, the PW is 
taken out of service and the operator advised as described in 
Section 6. 


Attention is drawn to the possible absence of fate sharing between PW 
data packets and VCCV CC Type 4 packets described in Section 3 and 
Section 4. 


8. Security Considerations 


This document does not by itself raise any new security 
considerations beyond those described in [RFC5085] and [RFC6073]. 
[RFC6073] provides detailed operational procedures that can be used 
to verify the MS-PW connectivity. In addition, the procedure 
Specified in this document eliminates the possibility of packet 
leaking that can occur with VCCV Type 3. 
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9. IANA Considerations 

9.1. MPLS VCCV Control Channel (CC) Type 4 
IANA has assigned a new bit from the MPLS VCCV Control Channel (CC) 
Types registry in the "Pseudowire Name Spaces (PWE3)" registry in 
order to identify VCCV type 4. 
MPLS VCCV Control Channel (CC) Types 


Bit (Value) Description Reference 


Bit 3 (0x08) Type 4: GAL RFC 7708 
9.2. LDP Status Code 


IANA has assigned a new Status Code from the "Label Distribution 
Protocol (LDP) Parameters" registry: 


Status Code Name Space 
Range/Value E Description Reference 


0x00000035 0 VCCV Type Error RFC 7708 
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